Health Portal
The health portal (the Edge Admin Portal) is an on-device web dashboard served on port 8080. It is your window into a single gateway: overall health verdict, per-component status, certificate expiry, live logs, a device-shadow viewer, a BLE session browser, an embedded terminal, and a GNSS/tool map. Almost everything it shows is read locally off the device, so the dashboard has no cloud dependency of its own. Read this if: you want to observe, verify, or debug a running gateway. Before this: skim the Overview.
The portal is a FastAPI app that runs as the health-portal Greengrass component. It is the fastest way to answer "is this gateway healthy, and if not, why?" without SSHing around the device by hand.
The portal exposes a root-capable terminal and WiFi/Greengrass controls with no authentication. It is meant for a fleet operator on a trusted dev device, not for production exposure. See the health-portal README.
Reaching it
Open http://<device-ip>:8080 in a browser on the same network as the device. For a headless check without a browser, GET /health returns the aggregated verdict as JSON, which is what make health DEVICE_IP=<ip> (or sudo bash tools/health.sh on the device) calls.
What it shows
| Panel | What it tells you | Source |
|---|---|---|
| Health verdict | Aggregated pass/fail across the nucleus, each component, the BLE adapter, GNSS, cell signal, last upload, and cert expiry. | GET /health (health.py) |
| Device shadows | View any of the four named shadows (identity, status, config, location); edit desired state for config only. | GET /shadows, GET/POST /shadows/{name} |
| Session browser | Browse the BLE scan session files the gateway has produced: pending, uploaded, and errors. | GET /sessions |
| Live logs | Stream a component's Greengrass log in the browser. | GET /logs/{component} |
| Embedded terminal | Run a shell command on the device from the browser (30-second timeout). | GET /terminal |
| GNSS / cell / tools map | The device's location and nearby detected tools on a map, plus cell-tower geolocation and GNSS/upload history. | GET /tools, GET /history, GET /towers |
| WiFi + actions | Read WiFi state, connect to a network, restart a component or Greengrass. | GET/POST /actions/* |
For verification specifically, the health verdict plus the shadow viewer answer most questions: components green, identity/status populated, location updating, cert not near expiry.
These are cellular-primary devices, so WiFi and the mesh side-channel are shown but deliberately excluded from the overall pass/fail. A degraded mesh will not flip a healthy gateway to fail.
The mesh map (experimental)
When the gateway is part of the experimental Edge Mesh, the portal also draws a live map of the mesh topology (nodes, link quality, and operator-placed node positions). That feature belongs to the Edge Mesh experiment; see the Edge Mesh Architecture page for how the portal reads the mesh. On a standalone reference gateway it simply reports that no mesh is present.
Where the code lives
components/health-portal/README.md: the full endpoint list, configuration keys, access-control policy, and internals.components/health-portal/src/: the app itself (main.pyhealth aggregation,health.pyindividual checks,shadows.py,sessions.py,terminal.py,mesh.py).- Getting Started: where the portal fits into standing up and verifying a gateway.